OBEX (OBject EXchange protocol) is well known as a communication protocol for transmitting and receiving data, i.e., for exchanging objects. OBEX is a protocol by which a procedure of transmitting and receiving data via an infrared port was standardized in the form of “object exchange”. The wording “object” refers to general data entity such as a file. (See Patent document 1).
Application software adopting OBEX can exchange various objects with other application software adopting OBEX, irrespective of differences in communication devices and/or communication methods. Thus, OBEX is adopted in a wide range of fields, as (i) not only a session protocol for the IrDA (Infra Red Data Association) communication method using an infrared ray, but also (ii) a session protocol for the Bluetooth® communication method using radio (2.4 GHz band).
Examples of such an object include a general file, device diagnostic, name card, bank statement, electrocardiogram, bill-payment receipt, and the like. Therefore, for example, OBEX allows exchanges of address book data and/or name card data among laptop personal computers, mobile phones, and PDAs (mobile information communication devices), each of which has a communication function using either IrDA or Bluetooth®. Further, OBEX can be also used in transmitting data of an image captured by a mobile phone or a digital still camera, to a television, a monitor, and/or a kiosk in a town. In addition, OBEX can be used for control of a television receiver or a VTR (video tape recorder).
OBEX is a high level IrDA protocol of a layer corresponding to the session layer of the OSI (Open System Interconnection) Reference Model. OBEX has a function similar to that of HTTP (Hyper Text Transform Protocol) used in the Internet. However, OBEX does not require resource as much as HTTP. This is a feature of OBEX.
FIG. 7 illustrates the standard IrDA protocol stack. The IrDA protocol stack includes: IrPHY (IrDA Physical Layer), IrLAP (IrDA Link Access Protocol), IrLMP (IrDA Link Management Protocol), and TinyTP (Transport Protocol). IrPHY defines a modulation method, signal intensity, directivity, and the like. IrLAP defines an error control function, transparent transmission, and flow control, each of which is in accordance with the multipurpose HDLC (High level Data Link Control). Moreover, IrLAP defines (i) a function of making negotiations with its counterpart about communication speed and/or a maximum data size before starting communication therebetween; (ii) a procedure of searching and finding an unspecified external device to which the device is to be connected; and the like. IrLMP provides a multiplexing/demultiplexing function corresponding to the port number used in TCP or UDP of TCP/IP protocol. Tiny TP is used for flow control in an individual logic link. OBEX is a protocol of a layer just above the layer using the transport protocol, i.e., Tiny TP.
In OBEX, a device making a request for a command is called “client device”, and a device making a response to the device in reply to the request is called “server device”. Usually, OBEX is in compliant with the client/server model in which the client device issues a request command such as a PUT or GET command to the server device and in which the server device sends a response command to the client device in reply to the request command.
Generally, examples of such a request command defined by OBEX include: (i) a CONNECT command for connecting the client device to the server device with which the client device is to communicate; (ii) a DISCONNECT command for disconnecting the client device from the server device with which the client device is being communicated; (iii) the PUT command for sending an object such as a file; (iv) the GET command for receiving an object such as a file; (v) a SETPATH command for changing a path (current path), to which an object is to be sent, of the sever device; and (vi) an ABORT command for forcefully aborting transmission and/or reception of an object.
FIG. 8 illustrates a basic case where the client device sends such a request command to the server device and where the client device sends such a response command to the client device in reply. When the client device receives an object exchange request from a user, the client device sends the CONNECT command to the server device in order to establish a connection with the server device. The CONNECT command represents the connection request.
The server device receives the CONNECT command, and sends a SUCCESS response command to the client device in cases where the server device is connectable to the client device. The client device receives the SUCCESS response command, with the result that connection is established between the client device and the server device.
After the connection is established, the client device starts exchanging objects with the server device. Specifically, the client device sends, to the server device, a PUT command for sending an object. When the server device receives normally the PUT command from the client device, the server device sends a CONTINUE response command to the client device. The client device receives the CONTINUE response command from the server device, and therefore confirms that the server device has received the PUT command normally. Thereafter, the client device sends a next PUT command to the server device. The client device sends PUT commands to the server device until the client device finishes sending all the objects. When the server device has finished receiving these PUT commands normally up to the final PUT command, the server device sends a SUCCESS response command to the client device.
The client device receives the SUCCESS response command from the server device, and then sends the DISCONNECT command to the server device so as to carry out a process for disconnecting the client device from the server device. The DISCONNECT command represents a disconnection request.
When the server device receives the DISCONNECT command, the server device sends, to the client server, a SUCCESS response command, which represents permission for the disconnecting. The client device receives the SUCCESS response command, with the result that the client device is disconnected from the server device. In this way, the series of the object exchange between the client device and the server device are completed.
As such, the object exchange using OBEX is carried out in such a manner that: the client device sends a request command to the server device, and the server device sends a response command to the client device in reply.
Further, as is the case with the aforementioned IrDA protocol stack, communication protocols in a hierarchical structure such as OSI respectively are used in layers, each of which defines header information independent from those respectively defined by the other layers. Therefore, in each of the layers, such header information is rendered to data to be sent from one computer to another. The rendering of the header information is carried out in the layers in order from the uppermost layer to the bottom layer. On the other hand, received data is passed on one by one from the bottom layer to the uppermost layer, after removing corresponding header information therefrom in each of the layers.
Specifically, see FIG. 9. In the client device, a request command generated in the OBEX layer is passed on one by one to the lower layers, i.e., the Tiny TP layer, the IrLMP layer, and the IrLAP layer, after rendering header information to the request command in each of the layers. The header information is independent from those of the other layers. On the other hand, in the server device, the data received from the client device is passed on one by one from the bottom layer to the uppermost layer, after removing corresponding header information therefrom in each of the layers. Therefore, the data passed to the OBEX layer of the server device is the request command (the CONNECT command, the PUT command, the DISCONNECT command, or the like) from which the header information corresponding to each of the layers below the OBEX layer have been removed.
Patent document 1: Japanese Unexamined Patent Publication Tokukai 2000-196622 (published on Jul. 14, 2000)
As described above, OBEX allows exchange of various objects, irrespective of the differences in communication devices and/or communication methods. Thus, OBEX is adopted as a protocol for object exchange in IrDA, Bluetooth®, and the like, and OBEX is therefore used in various devices such as a mobile terminal. Examples of the mobile terminal include a mobile phone, a PDA, and the like.
However, for realization of the object exchange between the client device and the server device each using OBEX, the server device inevitably needs to have a function of transmitting a response command to the client device. However, rendering of such a transmitting function to the server device causes increases in device cost and in development difficulty. Accordingly, there arises a demand for realizing object exchange in which the server device has only a minimally required receiving function.
Further, as described above, during the object exchange using the PUT commands of OBEX, the server device sends the CONTINUE response commands to the client device in reply to the PUT commands sent from the client device, respectively. The SUCCESS response command sent in reply to the final PUT command is required so as to notify the client device that the object exchange has been surely done. However, the CONTINUE response commands, each of which serves to notify the client device of progress in the object exchange, are not necessarily required in consideration of a band used for the transmission of the CONTINUE response commands.
Further, as described above, OBEX is currently used in various devices, so that it is not easy to change its specification. If the specification of OBEX is changed, existing resources cannot be used any more.